Internet Surfer 2.0/Internet Surfer 2.0 (Wayzata Technology) (1996).iso/pc/textfile/faqs/smalltal

Internet Message Format | 1992-12-26 | 30.8 KB

Xref: bloom-picayune.mit.edu comp.lang.smalltalk:5815 news.answers:4329
Path: bloom-picayune.mit.edu!enterpoop.mit.edu!spool.mu.edu!agate!con.Berkeley.EDU!latta
From: [e-mail] (Craig R. Latta)
Newsgroups: comp.lang.smalltalk,news.answers
Subject: Smalltalk Frequently-Asked Questions (FAQ)
Supersedes: <[e-mail]>
Followup-To: poster
Date: 1 Dec 1992 12:44:31 GMT
Organization: University of California, Berkeley
Lines: 847
Approved: [e-mail]
Distribution: world
Expires: 25 Dec 1992 12:45:14 GMT
Message-ID: <[e-mail]>
Reply-To: [e-mail]
NNTP-Posting-Host: con.berkeley.edu
Summary: This posting contains a list of frequently-asked questions
        (and their answers) about the Smalltalk programming
        language and environment. It should be read by posters
        to comp.lang.smalltalk.
Originator: [e-mail]

Archive-name: smalltalk-faq
Last-modified: 1992/12/1
Version: 3.0


***

    This is a Smalltalk frequently-asked-questions (FAQ) sheet,
distributed by Craig Latta ([e-mail]). It is posted
fortnightly to the USENET newsgroups comp.lang.smalltalk and
news.answers.
    It is also available via ftp as
anonymous@xcf:misc/smalltalk/FAQ/FAQ.entire. Finally, it can be
obtained by mail by emailing smalltalk-request@xcf with the subject
line "request for FAQ". The machine xcf.Berkeley.EDU has IP address
128.32.138.1.

        Please send contributions, suggestions and comments to
[e-mail]. Raw FAQ submissions (which I have
not yet incorporated into this document) are available (in 'mh'
message format) via 'ftp' as
[e-mail]:misc/smalltalk/FAQ/raw/*.
    Comments and suggestions are greatly appreciated. I realize
that information has a short half-life.

    Disclaimer: I am an employee of ParcPlace Systems, Inc., but I
am solely responsible for this FAQ and its contents. In August 1992, I
solicited comments about the appropriateness of my maintaining and
posting this FAQ. The feedback I got was unanimously approving.


        Thanks,

-C


    New items are marked with a '+'. Modified existing items are
marked with a '*'.

    Contents:

0.0)    [Meta-issues]
0.1)        How can I browse ftp sites and their data without
            using my own disk space (unless I want to keep
            data), and locate files on ftp sites, given
            pathname fragments?

1.0)     [Archival]
1.1)        How can I get GNU Smalltalk?
1.2)        What Smalltalk archives are there?

2.0)     [Projects]
2.1)        What is Smallmusic?

3.0)     [References]
3.1)        Can someone recommend a good introduction to
            Model-View-Controller concepts?
3.2)        Is there a Smalltalk bibliography?
3.3)+        What are the "blue book", "purple book", etc?

4.0)+    [Programming issues]
4.1)+        What are some "classic Smalltalk bugs", both in the
            system and programmer domains?

---

0.0) [Meta-issues]

---

0.1)        How can I browse ftp sites and their data without
            using my own disk space (unless I want to keep
            data), and locate files on ftp sites, given
            pathname fragments?

Answer:

    This question might seem tangential at first (and I suppose it
is). But it is vitally important, as resources such as papers,
documentation, code and software tools become more numerous and
distributed.

        There is a set of Emacs-Lisp ("elisp") code, called
"ange-ftp.el", which makes 'ftp' use transparent within GNU Emacs (GNU
Emacs is available via anonymous ftp from prep.ai.mit.edu). This
package attempts to make accessing files and directories using FTP
from within GNU Emacs as simple and transparent as possible.  A subset
of the common file-handling routines are extended to interact with
FTP. Using these routines, one is able to access remote files and one
would any other local file, without having to write it locally to
disk. The result is an immense virtual global filesystem.
        The routines are available via anonymous ftp (naturally!) as
tut.cis.ohio-state.edu:/gnu/emacs/elisp-archive/as-is/ange-ftp.el.Z,
(incidentally, if you already had "ange-ftp.el", you could paste the
above line in response to Emacs' 'copy-file', stick "/anonyous@" in
front of it, and copy the file.) My current version is dated 22
October 1991.
        Another useful bit of elisp is "saveconf.el". It saves the
Emacs buffer list and window configuration between editing sessions.
So, one can have several buffers, with several files open (as I
usually do), quit and restart Emacs, and have the state preserved,
cursor locations and windows included. Happily, it works well with
"ange-ftp.el", so that even remote files are restored (after possibly
having to prompt for passwords). "context.el" is also available via
anonymous ftp from cis.ohio-state.edu, as
pub/gnu/emacs/elisp-archive/saveconf.el.Z. Also look for
"tree-dired.el" which provides for hierarchical directory editing.
        Incidentally, it was very easy to produce references for the
above tools, thanks to another tool called "archie", developed at
McGill University. Dubbed a "resource discovery tool" by its authors,
it comes in very handy when one knows what tools are needed but not
their availability. Archie consists of a server for this information
(basically from a database of directory trees from "all known"
anonymous ftp sites, updated once per month), and a client, which may
be run via 'telnet' from the server machine itself (frowned upon...),
or from a standalone client available from that machine (...highly
encouraged, for the considerable host load win). Some clients even
perform ftp tasks based on user response to search results. There are
clients available for dumb and X terminals as well as for (of course)
Emacs. Poke around archie.mcgill.ca for a client and documentation.

    Porting these tools (or at least new interfaces to them) to
Smalltalk would be a great project. I'm working on it in my spare
time. I'd love to hear from any interested people.


-Craig


---

1.0)     [Archival]

---

1.1)        How can I get GNU Smalltalk?

Answer:

    The most current location, to my knowledge, is
[e-mail]:pub/gnu/smalltalk-1.1.1.tar.Z. Please direct
problems to the author, Steven Byrne, at [e-mail].


---

1.2)        What Smalltalk archives are there?

Answer:

    There are many. Most of them simply archive GNU smalltalk, but
there are also a few large archives containing many interesting and
varied sources. All of the sites may be retrieved by invoking 'archie
smalltalk' (see above reference to 'archie').
    For convenience, descriptions of a few of the archives follow.
If you have a site/announcement you'd like included, please let me
know.


**

Directory: [e-mail]:misc/smalltalk
Summary:

    Smalltalk FAQ, smallmusic discussion archive.

**

Host: mushroom.cs.man.ac.uk
Summary: The Manchester Smalltalk archive. Information about it is
    posted regularly to comp.lang.smalltalk.

**

File: [e-mail]:pub/Index
Summary: Information about the UIUC Smalltalk archive (which has local
    files and a mirror of the Manchester archive).

**

File: [e-mail]:pub/st80/README
Summary: Information about various Smalltalk-related offerings,
    including the Musical Object Development Environment (MODE).


---

2.0)     [Projects]

---

2.1)        What is Smallmusic?

Answer:

    A work group has formed to discuss and develop an
object-oriented software system for music. The current environment is
Smalltalk 80. The email address for the group is
[e-mail].  If you are interested in joining the
discussion, email [e-mail], with the
subject line "add me".

    The abstract and outline to a recent version of our working
paper follows. The document is available via ftp as
[e-mail]:pub/st80/OOMR6.t.


    Thanks,

    Craig Latta
    [e-mail]

***

Abstract to the working document

    This document describes an object-oriented description
language for musical parameters, events and structures known as the
Smallmusic Object Kernel (SmOKe) .  In object-oriented software terms,
the representation is described in terms of software class hierarchies
of objects that share state and behavior and implement the description
language as their protocol.
    The authors believe this representation, and its proposed
linear ASCII description in Smalltalk-80 syntax, to be well-suited as
a basis for: (1) concrete description languages in other languages,
(2) specially-designed binary storage and interchange formats, and (3)
use within and between interactive multi-media, hypermedia
applications in several application domains.


---

3.0)     [References]

---

3.1)        Can someone recommend a good introduction to
            Model-View-Controller concepts?

Answer:

From: [e-mail] (Dr. Raimund K. Ege)
Newsgroups: comp.lang.smalltalk
Subject: Re: MVC -- good introductions?
Date: 8 Mar 92 18:26:40 GMT
Organization: Florida International Univ.

Look at Chapter 10 in the following book that just came out:

Programming in an Object-Oriented Environment,
by Raimund K. Ege

Academic Press, Inc., San Diego, CA, 1992, hardcover,
ISBN 0-12-232930-9

To order call 1-800-321-5068.

(also: Academic Press Limited, London, United Kingdom)

It presents a complete and thorough introduction to all object-oriented
concepts. It contains a large
example/case study, and a comparison of major OO programming languages.

In addition, the book extends the object-oriented view
to all elements of the programming environment: data structures
and algorithms, programming tools, user interfaces, data bases and
software design.

Chapter 10 is on user interfaces: it describes and illustrates
the Smalltalk MVC paradigm (also: InterViews)

--
Raimund K. Ege                             School of Computer Science
                                             Florida Int'l University
[e-mail]           [phone]              University Park
[e-mail]     FAX [phone]              Miami, FL 33199

**

From: [e-mail] (Nils Erik Asmundvaag)
Newsgroups: comp.lang.smalltalk
Subject: Re: MVC -- good introductions?
Date: 11 Mar 92 10:56:38 GMT
Organization: Glasgow University Computing Science Dept.

The book

    Smalltalk-80: A Practical Introduction
    (ISBN 0-273-03105-8)

    by Philip D. Gray & Ramzan Mohamed, 1990
    and published by Pitman (at least in the UK)

contains two chapters on interactive applications and the MVC.

I found it very helpful when first learning about the MVC.

Nils E. Asmundvaag

--
-------------------------------------------------------------------------------
Nils Erik Asmundvaag
University of Glasgow, Scotland
[e-mail]      [e-mail]


**

From: [e-mail] (Bruce Samuelson)
Newsgroups: comp.lang.smalltalk
Subject: Re: how are st80 views and controllers used?
Date: 12 Mar 92 14:12:48 GMT
Organization: UTexas at Arlington, Linguistics

There are two papers on MVC that provide an introductory overview of
the pre-version 4.0 ST80 scheme.  Much of what's in them also applies
to version 4.0.  I understand that one of PPS's priorities in the
forthcoming version 4.1 will be improved documentation.  We'll see how
well they explain the new windowing scheme launched in version 4.0.
It would certainly be helpful to get an overview of what's going on
before plunging into the source code of the myriad new classes.

(1) A Cookbook for using the Model-View-Controller User Interface
Paradigm in Smalltalk-80 by Glenn E. Krasner and Stephen T. Pope,
ParcPlace Systems, copyright 1988.

(2) Applications Programming in Smalltalk-80: How to Use
Model-View-Controller (MVC) by Steve Burbeck, Softsmarts, Inc.,
copyright 1987.

The first paper may still be in print.  Try [e-mail].

The second paper is probably no longer available.  I think Softsmarts
is the company that used to sell a version of Smalltalk for 80286
machines but went out of business some years ago.  The phone number on
the paper is listed as 415-327-8100 (Palo Alto, California).  You may
try asking ParcPlace (or, less likely, Digitalk) if they have copies
of Burbeck's paper.

--
**********************************************************
* Bruce Samuelson    Department of Linguistics     *
* [e-mail]    University of Texas at Arlington *
**********************************************************


---

3.2)        Is there a Smalltalk bibliography?

Answer:

    There are many... here is one:

From: [e-mail] (Ronald Schultz)
Newsgroups: comp.lang.smalltalk
Subject: Smalltalk Relevant Texts
Date: 10 Jan 92 16:08:05 GMT
Organization: Grebyn Timesharing


A list of Smalltalk-relevant texts.  Retrieved from the Digitalk
forum on Compuserve.  If you know of any additional texts, please
let me know.  Thanx.


==========================================================================
Ron Schultz
Berard Software Engineering, Inc.
Columbus Ohio Office                           Headquarters
5634 Claire Court                              301 Lakeforest Drive
Dublin, Ohio 43017                             Gaithersburg, Md. 20877
Phone  [phone]                          [phone]
FAX    [phone]                          [phone]
=========================================================================

Smalltalk 80 The Language, Adele Goldberg & David Robson
        Addison-Wesley 1989             ISBN 0-201-13688-0

Smalltalk 80 The Interactive Programming Environment, Adele Goldberg
        Addison Wesley 1984             ISBN 0-201-11372-4

Smalltalk 80 Bits of History, Words of Advice , Glenn Krasner
        Addison Wesley 1984             ISBN 0-201-11669-3

Inside Smalltalk Volume I, Wilf Lalonde & John Pugh
        Prentice Hall 1991              ISBN 0-13-468414-1

Inside Smalltalk Volume II, Wilf Lalonde & John Pugh
        Prentice Hall 1991              ISBN 0-13-465964-3

Object-Oriented Graphics, P. Wisskirchen
    Springer-Verlag 1990        ISBN 3-540-52859-8

Practical Smalltalk: Using Smalltalk/V, Dan Shafer and Dean A. Ritz.
        Springer-Verlag                 ISBN 0-387-97394-X

Rapid Prototyping for Object Oriented Systems, Mark Mullen
        Addison Wesley 1990             ISBN 0-201-55024-5

Object-Oriented Design, Peter Coad and Ed Yourdon
    Yourdon Press 1991        ISBN 0-13-630070-7

Object Oriented Programming for Artificial Intelligence, Ernest Tello
        Addison Wesley 1989             ISBN 0-201-09228-x

The Well Tempered Object, Stephen Travis Pope
        MIT Press 1991                  ISBN 0-262-16126-5

RefTalk/Vwin, David Carl O'Neal
        NuVista Press 1991              ISBN pending

Human-Computer Interface Design Guidelines, C. Marlin Brown
        Ablex Publishing 1989           ISBN 0-89391-332-4

Designing Object-Oriented Software,
                Rebecca Wirfs-Brock, Brian Wilkerson, and Lauren Wiener
        Prentice-Hall 1990              ISBN 0-13-629825-7

Object Oriented Programming with Smalltalk/V, Dusko Savic
        Ellis Horwood 1990              ISBN 0-13-040692-9

An Introduction to Object Oriented Programming & Smalltalk
        Lewis Pinson & Richard Wiener
        Addison Wesley 1988             ISBN 0-201-19127-x

SAA Common User Access Advanced Interface Design Guide
        IBM 1989                        IBM Document # SC26-4582-0

IBM Red Books----(available from your IBM representative
                  contact your local office of IBM and request
                  the placing of an IBM Red Book Order.  If you
                  are an IBM customer, the books are free.  If you
                  are not an IBM customer, the books may have a nominal
                  fee.)----

A Practical Introduction to Object Oriented Programming
        IBM 1990                        IBM Document # GG24-3641

Object Oriented Design - A preliminary Approach
        IBM 1990                        IBM Document # GG24-3647

Developing a CUA Workplace Application
        IBM 1990                        IBM Document # GG24-3580-00

Managing the Development of Object Oriented Applications
        IBM 1990                        IBM Document # GG24-3581-00

Object Oriented Analysis of the ITSO Common Scenario
        IBM 1990                        IBM Document # GG24-3566

CUA Evaluation
        IBM 1990                        IBM Document # GG24-3456

SAA CUA '91 Guide
        IBM 1991                        IBM Document # SC34-4289

SAA CUA '91 Reference
        IBM 1991                        IBM Document # SC34-4290

SAA - A Guide for Evaluating Applications
        IBM 1991                        IBM Document # G320-9803


---

3.3)+        What are the "blue book", "purple book", etc?

Answer:

Date: Wed, 11 Nov 92 12:52:39 PST
From: [e-mail] (Mike Khaw)


blue
        Goldberg, Adele, and David Robson, _Smalltalk-80: The Language
        and Its Implementation_, Addison-Wesley, 1983. ISBN
    0-201-11371-6. *Out of print*

orange
        Goldberg, Adele, _Smalltalk-80: the Interactive Programming
        Environment_, Addison-Wesley, 1984. ISBN 0-201-11372-4.

green
        Krasner, Glenn, ed., _Smalltalk-80: Bits of History, Words of
        Advice_, Addison-Wesley, 1983, ISBN 0-201-11669-3

purple
        Goldberg, Adele, and David Robson, _Smalltalk-80: The Language_,
        Addison-Wesley, 1989, ISBN 0-201-13688-0

The books are actually cream or tan. The color referred to is the color
used as the background of the illustration on the front cover (as well
as for the Addison-Wesley logo on the spine).

The purple book is an update/revision of the blue book, with the
section on the abstract bytecode machine omitted (because it was out
of date, according to Adele).
----------

Mike


---

4.0)+    [Programming issues]

---

4.1)+        What are some "classic Smalltalk bugs", both in the
            system and programmer domains?

Answer:

Newsgroups: comp.lang.smalltalk
From: [e-mail] (Ralph Johnson)
Subject: catalog of classic bugs
Summary: version 1 of the catalog of classic Smalltalk bugs
Organization: University of Illinois, Dept. of Comp. Sci., Urbana, IL
Date: Wed, 12 Aug 1992 22:29:16 GMT

Classic Smalltalk Bugs

compiled by Ralph Johnson -- University of Illinois at Urbana-Champaign

Every programming system is prone to certain kinds of bugs.  A good
programmer learns these bugs, and how to avoid them.  Smalltalk is
no different.  Smalltalk eliminates lots of bugs that are common in
other languages, such as bugs in linear search algorithms.  (Just use do:)
However, it has its own set of classic bugs, which every new Smalltalk
programmer runs into.

There are several reasons to collect classic bugs.  The first is that
it will help experienced programmers test and debug programs, and can
help us design better programs in the first place.  Second, if we
teach these bugs up front then people should learn to be good
programmers faster.  Third, perhaps we can redesign the system to
eliminate some of these bugs, or we can write checking tools to
spot them automatically.

Bug 1: Variable-sized classes

Set, Dictionary, and OrderedCollection are variable-sized classes
that grow.  They grow by making a copy of themselves and "becoming"
the copy.  If you add new instance variables to a subclass then
you have to make sure that these instance variables get copied, too,
or else you will mysteriously lose the values of the instance
variables at random points in time.

Smalltalk-80 R4.0 (and probably some earlier versions) has a
copyEmpty: method in Collection that you are supposed to override
if you make a subclass of Collection that adds instance varaibles.
The solution to this bug is to write a version of copyEmpty: for
your class.

It has been suggested that it would be easy to write a tool that
checked that every new subclass of Collection that added instance
variables also defined a method for copyEmpty:.

Collection bugs

Bug 2: add: returns its argument

For every collection that grows, add: returns its argument,
not the receiver, and people usually assume that it returns
its receiver.  Thus, they write "(c add: x) add: y" when they should
really write "c add: x; add: y" or else "c add: x. c add: y".
Note that this is one of the good uses for "yourself", you can write
(Set new
    add: x;
    add: y;
    ...;
    yourself)
to make sure that you have the new Set.

Note that there are good reasons why add: returns its arguments,
and even if there weren't, it is a very, very bad mistake to
implement add: so that it returns the receiver, and so confuse
every other Smalltalk programmer on the planet.
Making add: return its argument often keeps you from resorting
to temps, because you can create the argument to add: on the
fly, and then do other things with it after the add:.  If you
want to access the collection, you can do it with yourself or
cascaded messages, as described above.

Bug 3: changing collection while iterating over it

You should never, never, never iterate over a collection which
the iteration loop somehow modifies. Elements of the collection
will be moved during the iteration, and elements might be missed
or handled twice.  Instead, make a copy of the collection you
are iterating over, i.e.
   aCollection copy do: [:each | aCollection remove: each]
is a good program, but if you leave out the copy then it isn't.

Mario Wolczko suggested a solution that catches this problem the
instance it occurs (at some performance penalty of course).  The
solution is to change the collection classes.  Each iteration method
enters that collection into a set of collections being iterated over
(IteratedCollections), executes the block, then removes the collection
from the set.  Collections are usually (only?) modified using at:put:
or basicAt:put:, so these are overriden to check that the collection
is not in IteratedCollections.  If it is, an error is signalled.  You
can either use this technique all the time, or you can just install
these classes when you are testing and debugging your program.  These
changes are packaged in a file Iterator-check.st that is available on
the Manchester and Illinois servers.  On the Illinois server, it is
in /pub/MANCHESTER/manchester/4.0/Iterator-check.st.

Bug 4: modifying copies of collections

It is common for an object to have an accessing method that returns a
collection of objects that you can modify.  However, sometimes
an object will return a copy of this collection to keep you from
modifying it.  Instead, you are probably supposed to use messages
that will change the collection for you.  The problem is that this
is often poorly documented, and a person who likes to modify collections
directly will run into problems.  See  "ScheduledControllers
scheduledControllers" for an example.

The solution is to either provide better documentation, to claim
that nobody is allowed to modify copies of collections returned
from other objects, or to have objects that don't want their
collections modified to return immutable versions of the collections
that will give an error if you try to modify them.

Bug 5: Missing ^

It is very easy to leave off a return caret on an expression.
If there is no return at the end of a method, Smalltalk returns
the receiver of the method.  It only takes one missing return
to mess up a long chain of method invocations.

Bug 6: Class instance creation methods

Writing a correct instance create method is apparently non-trivial.
The correct way to do it is to have something like
new
  ^super new init
where you redefine init in each class to initialize that class's
instance variables.  In turn, init is defined as a class method
init
  super init "to initialize inherited instance variables"
  "initialize variables that I define"

There are lots of ways to do this wrong.  Perhaps the most common
is to forget the return, i.e. to write
   super new init
The result is that you have the class where you want the instance of
the class.  This is a special case of bug #?.

Another error is to make an infinite loop by writing
  ^self new init

If Smalltalk doesn't respond when you think it should, press ^C to
get the debugger.  If the debugger shows a stack of "new" messages
then you know you made this mistake.

Finally, you should only define "new" once for each class hierarchy
and let subclasses inherit the method.  If you redefine it in each
class then you will reinitialize the new object many times, wasting
time and perhaps memory.

One way to keep this from happening is to make the "new" method in
Object send init, and have the "init" method in Object do nothing.
Of course, sometimes the version of init that you define has arguments,
and this wouldn't help those cases.  It is probably better to rely
on education to eliminate this kind of error.

Bug 7: Recompiling bugs in Smalltalk/V

It is easy to have references to obsolete objects in Smalltalk/V
if you change code without cleaning things up carefully. For example,
the associations whose keys are the referenced names in the Pool
Dictionary are stored in the CompiledMethods at compile time. If you
create a new version of the Pool Dictionary and install it by simple
assignment then the compiled methods still refer to the old associations.

If you substitute a new instance of Dictionary or replace, rather than
update an association in a pool dictionary, you have to recompile all
methods using variables scoped to that Pool.

This is is also annoying when using ENVY, where the methods are under
strict control. Perhaps Pool Dictionaries should be be first-class
versioned pre-requisites of Classes, just like the class definition.

BTW we are using/VPM 1.4 with ENVY 1.3

1. If you prune & graft a subtree of your class structure you have to
make sure that all referencing methods are recompiled. Otherwise you
will run (or your customer, because this is only detected at run time)
into an Deleted class error message.
Thomas Muhr posted a "Bite" a while ago to handle this problem for
Smalltalk/V 286.

Bug 8: Opening windows

Neither Smalltalk-80 nor Smalltalk-V return to the sender when a
new window is opened in a standard fashion. Thus, any code after
a message to open a window will never be executed.  This is the
cause of much frustration.  For example, if you try to open two
windows at once, i.e.

TextPane new open.
TextPane new open

is Smalltalk-V and

aScheduledWindow1 open.
aScheduledWindow2 open

in Smalltalk-80, then you will get only one open window,
and one forgotten piece of code.

I don't know the fix for Smalltalk-V.  The fix for Smalltalk-80 is
to use the openNoTerminate method to open the window, which does
not transfer control to it.  A useful trick is to store the new
window in a global variable so you can test it.  In earlier
versions of Smalltalk-80, open would obliterate the current
process, not just never return to it.  In Version 4.1 that
never happens.

Bug 9: blocks

Blocks are very powerful, and it isn't hard for programmers to get
into trouble trying to be too tricky.  To compound problems, the
two versions of Smalltalk have slightly different semantics for
blocks, and one of them often leads to problems.

Originally blocks did not have truly local variables.  The block
parameters were really local variables in the enclosing method.
Thus,

| x y |
  x := 0.
  (1 to: 100) do: [:z | x := x + z]

actually had three temporaries, x, y, and z.  This leads to bugs
like the following

someMethod

 | a b  |
 a := #(4 3 2 1).
 b := SortedCollection sortBlock: [:a :b | a someOperation: b].
 b addAll: a.
 Transcript show: a.

When elements are added to b, the sortBlock is used to tell where
to put them, but this will change a and b.  addAll: is OK, but
the "a" that gets displayed on the transcript will be an integer,
not an array.

Early versions of Smalltalk-80 (2.4 and before?) implemented blocks
like this, and Smalltalk/V still does.  However, in current PPS
implementations, blocks are close to being closures. You can declare
variables local to a block, and the names of the block parameters are
local to the block. Most people agree that this is a much better
definition of blocks than the original one.  Nevertheless, people
planning to use Smalltalk/V should realise that it has a different
semantics for blocks.

This difference can lead to some amusing problems.  For example, here
is some code written by someone who had obviously learned Scheme.

| anotherArray aBlockArray |

aBlockArray := Array new: 4.
anotherArray := #(1 2 4 8).

1 to: 4 do: [ :anIndex |
 aBlockArray at: anIndex put: [ (anotherArray at: anIndex) * 2 ]].


The programmer expected that each block would be stored in the array
along with its own value of anIndex.  If anIndex were just a local
variable of the method then this will not work.  It assumes that
each execution of the block gets its own version of anIndex, and
Smalltalk/V and old Smalltalk-80 actually make each execution share
the same version.

So, if you are using Smalltalk/V then be careful not to reuse the
names of arguments of blocks unless you know that the blocks are
not going to have their lives overlap.  Thus,

  aCollect do: [:i | ...].
  bCollect do: [:i | ...].

is probably OK because do: does not store its argument, so the
blocks will be garbage by the time the method is finished.
However, if the first block were stored in a variable somewhere
and evaluated during the execution of the second block then
problems would probably occur.

Bug 10: Smalltalk/V class library
Thomas Muhr makes these comments about bugs in the Smalltalk/V
class library that you should know if you want to keep your
programs fast and correct.

2. Never use symbols to label objects if you are dealing with many
objects. This will slow down your system to an almost dead halt. Use
strings instead.
3. Never use Sets when you can otherwise assure the uniqueness. Look
at the implementation of "add:" for Sets and you'll know what I mean:
on every "add:" the new element is compared to all others resulting
into a nonlinear time for adding to Sets.
4. Do not think that if you "collect:" something from a
SortedCollection, that your result will be sorted as the origin,
unless you use the default sortBlock. This is one of the bugs provided
by the language vendor



Many thanks to the many people who contributed bugs or solutions to bugs
to the list.  These include

 [e-mail] (Thomas Muhr)
 [e-mail] (Jan Steinman)
 [e-mail] (Alan Knight)
 [e-mail] (Mario Wolczko)
 [e-mail] (Peter Goodall)
 Aad Nales <[e-mail]>
 [e-mail] (Simon Lewis)
 [e-mail] (Mike Smith)
 [e-mail] (Naci Dai)
 [e-mail] (Dave Robbins)
 [e-mail] (Randy Stafford)
 [e-mail] (Hubert Baumeister)
 [e-mail] (Eliot Miranda)
 [e-mail] (donald)
 [e-mail] (Amir Bakhtiar)
 Kurt Piersol <[e-mail]>
 [e-mail] (Michael Sullivan)
 [e-mail] (Terry)
 [e-mail] (Brent Sterner)
 [e-mail]
 [e-mail] (Nicole Tedesco)
 [e-mail] (Rik Fischer Smoody)
 [e-mail] (Marten Feldtmann)

Comments and additions are welcome.  Please post to comp.lang.smalltalk
or e-mail to [e-mail].

---

End of Smalltalk FAQ